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In this paper we apply the UML-RSDS notation and tools to the "Hello World" case studies and 
explain the underlying development process for this model transformation approach. 

1 Specification of model transformations 

In UML-RSDS a transformation specification is written in first-order logic and OCL, and consists of the 
following predicates: 

1 . A global specification, Cons, of a model transformation, expresses in a platform-independent man- 
ner the overall effect of the transformation, as a relation between the source and target models. It 
is intended to hold true at termination of the transformation. 

2. A predicate Asm expresses the assumptions made about the source and target models at the start 
of the transformation, for example, that the target model is empty and that the source model is 
syntactically correct wrt the source language. 

The specification is therefore independent of any specific model transformation implementation lan- 
guage, and can be used as the basis for development in many such languages. By making explicit the 
semantic assumptions on source and target models, the specification assists in the verification (formal or 
informal) of model transformations. 

Cons can often be written in conjunctive-implicative form O, as a conjunction of constraints of the 
form 

Vs : S ■ SCond implies 3 1 : T ■ Post 

where S is a source language entity and T is a target language entity. This pattern is applicable to re- 
expression transformations such as model migrations, and to abstraction and refinement transformations. 

The patterns assist in the derivation of explicit PSM designs from the specification, consisting of 
a sequence of phases, which apply specific rules or operations to achieve the specification constraints. 
Provided that the updates defined in Post do not affect the data read in SCond or Post, and that the extent 
of S is fixed throughout the transformation (*), then a constraint of the above form can be implemented 
by an iteration 

for s : S do s.opi) 

where op implements the constraint for a particular S object. 

This iteration constitutes a single phase in the design. The possible orderings of phases are deter- 
mined by defining a partial order over the target language entities: T\ < T2 if T\ is used in Cons to define 
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a feature of T 2 (or a feature of a subclass of T 2 ). Any phase that creates T 2 instances must therefore be 
preceded by all phases that create T\ instances. 

The restriction (*) is termed the non-interference condition. 

The iterative phase activities derived from the constraints are also terminating and they establish the 
truth of their corresponding constraint, by construction. The PSM design is derived from the constraints, 
together with an executable Java implementation, using the UML-RSDS toolset J2[. The resulting ex- 
ecutable is a stand-alone implementation of the transformation, operating upon simple text format files 
defining input and output models. 

2 Simple transformation tasks 

Here we give the specifications and implementations of the simple transformation tasks in (T). All of 
these tasks satisfy the restrictions described above, so they can be specified and designed directly in 
UML-RSDS. 

2.1 Hello world transformation 

This has the global specification {Cons predicate): 

3g : Greeting ■ g.text = "Hello" and 

3p : Person ■ g.whom = p and p. name = "World" 

This predicate is coded in UML-RSDS as the only postcondition 

Greetings exists{ g \ g.text = "Hello" & 

Persons exists{ p \ g.whom = p & p.name = "World" ) ) 

of a use case which represents the transformation. From this an implementation is automatically gener- 
ated in Java. 

2.2 Graph properties 

Figure [2] shows the basic graph metamodel in the UML-RSDS tools, and the generated design and Java 
code of the specification. 

We assume that the following constraint AsmO of the source model holds: 

Vg : Graph ■ g.edges.src C g.nodes and g.edges.trg C g.nodes 

The queries are simple examples of abstraction transformations, and can be specified as follows: 
The constraint 

lntResult^exists( r \ r.num = nodes^-siz,e() ) 

on Graph expresses that for each graph there is a result object recording the number of nodes in the 
graph. An operation op\{) is generated to implement the constraint. 
Likewise for the other queries: 

lntResult^exists{ r \ r.num = edges^select{src = trg & trg ^ {})— >size() ) 

counts the number of looping edges in each graph, and is implemented by an operation op2(). 
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IntResult^exists( r \ r.num = g.edges^select{src = {} or trg = {})— tsizeQ ) 

counts the number of dangling edges and is implemented by an iteration of an operation op3() on graphs. 

IntResult^exists( r \ r.num = (g.nodes — (g.edges.src U g. edges. trg))^-size() ) 

counts the number of nodes that are not the source or target of any edge. — denotes set subtraction and 
U set union. This is implemented by an operation op4(). 

We extend the final query problem by defining an auxiliary entity which records the 3-cycles in the 
graph (Figured]). 
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Figure 1 : Extended graph metamodel 

The specification Cons of this transformation then defines how unique elements of ThreeCycle are 
derived from the graph, and returns the cardinality of this type in the end state of the transformation: 

(CI): 

el : edges & el : edges & e3 : edges & 

eX.trg = el.src & el.trg = e3.src & e3.trg = el. src & 

(el.src Ue2. src Ue3. src)— >size() =3 => 

ThreeCycle^exists\(tc \ tc. elements = {el.src Ue2. src Ue3.src) & tc : cycles) 

(C2) : IntResult—>exists(r \ r.num = cycles^siz,e()) 

Both constraints are on Graph. 

The order of nodes in a cycle is not distinguished by CI, if this was required then elements should 
be ordered (a sequence). Because of AsmO, each three-cycle will consist of nodes in a single graph. The 
unique existential quantifier 3 { specifies that there must exist exactly one object satisfying the quantified 
properties, ie, duplicated cycles are not included in cycles. 

Each constraint is refined by a specific phase in the design. The exists! quantifier is implemented by 
checking that there is no existing ThreeCycle with the required property, before creating such an element. 

An alternative approach would be to evaluate the set of three cycles in a single expression: 

edges^collect(el, e2,e3 \ {el,e2,e3})^asSet()^-select(s \ 
s^-siz,e() = 3 & s.src = s.trg)—>size() 

but we consider that the approach using ThreeCycle is more clear. 
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2.3 Reverse edges 

The global specification Cons for this transformation is: 

src = trg@pre & trg = src@pre 

on Edge. The suffix @pre denotes the value of the expression at the start of the transformation. This is 
the usual style of specification for update-in-place transformations. 

2.4 Simple migration 

The metamodels for this re-expression transformation are shown in Figure [3l together with extracts from 
example input and output models (on the left and right hand sides, respectively). 

We make the additional assumption Asml that the target model is empty at the start of the transfor- 
mation: 

ModelElementl = {} 

We can specify this transformation by three constraints, defined as the postconditions of a single use 
case of the system: 

(CI) : Node2-^rexists(n2 \ nl.idl = idl & nl.text = name) 

(C2) : Edge2—> exists \e1 \ el.idl = idl & el.text = "" & 

el.srcl = Node2[srcl.idl] and el.trgl = Node2[trgl .idl]) 

CI is a constraint on Nodel, and C2 on Edgel. Node2[srcl.idl] denotes the set of Node2 objects with 
primary key idl value in the set srcl.idl. 

(C3) : Graph2—'exists(g2 \ g2.id2 = idl & 

g2.gcs = Node2[nodes.idl] U Edge2[edges.idl]) 

C3 is a constraint on Graphl. A design can be automatically generated from these constraints, this 
implements each constraint by a separate phase in a three-phase algorithm. The ordering of the phases 
follows from the ordering of the entities Node2 < Edge2 < Graphl in the target language, based upon 
the dependencies between these entities in the specification constraints (Edge2 instances depend upon 
Node2 instances, etc). 

2.5 Delete nodes 

The global specification of this update-in-place transformation can be written as: 

edges^select{src .name = nl or trg.name = nl)^isDeleted() & 
nodes^rselect{name = nl)^isDeletedQ 

on Graph. The predicate also serves as the definition of an operation removeis : String) of Graph that 
implements the transformation. Since edges depend on nodes, edges are deleted before nodes (the reverse 
to the ordering used in construction of a model). 
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2.6 Insert transitive edges 

This can be considered as a simple example of a quality-improvement model transformation. Such 
transformations are typically update-in-place transformations, and have an associated quality measure 
Q : N on the models, used to show termination of the transformation. The transformation aims to reduce 
Q to in the target model. In this case Q is the number of pairs of distinct non-dangling edges el, el of 
the source model with el.trg = el.src and with no existing edge from el.src to el.trg. 
Under the assumption Asml that there are not already any duplicate edges in the graph: 

Vel,e2 : Edge ■ el.src = el.src implies el.trg ^ el.trg 

the specification of this transformation can be written as: 

{Cons) : 

el : edges@pre & el : edges@pre & 
el.trg = el.src & el.src ^ {} & 
el.trg ^{}& el.trg ^{} 

Edge^-existsl(e3 \ e3.src = el.src & e3.trg = el.trg & e3 : edges) 

on Graph. This satisfies the non-interference condition (since the created e3 edges are distinct and are not 
included in the sets of edges being iterated over), so permitting an implementation using fixed iterations. 
If instead the transitive closure R + of R was required, Cons would use edges instead of edges @ pre, and 
a more complex implementation strategy would be required, using repeated iteration until a fixed point 
is reached O. 

3 Conclusion 

We have shown that UML-RSDS can specify the case study transformations in a direct manner as high- 
level specifications, from which designs and executable implementations can be automatically generated. 
UML-RSDS has the advantage of using standard UML and OCL notations to specify transformations, 
reducing the cost of learning a special-purpose transformation language. Our method also has the advan- 
tage of making explicit all assumptions on models (eg, AsmO above) and providing global specifications 
(Cons, Asm) of transformations, independent of specific rules. 

Further work includes linking UML-RSDS to Eclipse/EMF to enable the use of ecore metamodels 
and import/export of Eclipse/EMF models. 
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Appendix A: Transforming specific models 

Source and target metamodels are defined using the visual class diagram editor of UML-RSDS (Figures|2]and|3]l. 
Metamodels cannot contain multiple inheritance, and all non-leaf classes must be abstract. Metamodels can be 
saved to a file by the Save data command. 




Figure 2: Graph metamodel and queries in UML-RSDS 

Source models can be defined in text files, which are then read by the executable implementation of the 
transformation metaclass, in a textual form. For example, a test model of the simple graph metamodel can be 
defined as follows: 

g : Graph 
nl : Node 
nl.name = "nl" 
nl : g. nodes 
n2 : Node 
n2.name = "n2" 
n2 : g. nodes 
e : Edge 
nl : e.src 
n2 : e.trg 
e : g. edges 

This defines a single edge from the first to the second node. Alternative models can be defined in a similar way. 

The UML-RSDS toolset is located at http://www.dcs.kcl.ac.uk/staff/kcl/uml2web. UML-RSDS 
can be executed by the command java UmlTool. The directory output is used to store metamodels, input and 
output models, and the generated Java code. The command Load data loads a metamodel from a file (eg, mig2.txt 
for the migration metamodel). The command Synthesis Java generates the Java executable of a transformation, 
this generated executable is the Controller, java file in the output directory. This can be compiled and used 
independently of the toolset. 
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Figure 3: Graph migration metamodels 



